QRZ! Ham Radio 4

home *** CD-ROM | disk | FTP | other *** search

/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / files / tcpip / pe1chl / netdoc1.arc / SAT.TXT

Wrap

Text File | 1992-02-05 | 33.6 KB | 829 lines

Notes on the use of NET with Satellites (A beginners Guide to PE1CHL NET) David Medley KI6QE INTRODUCTION Many of us have heard or read about a program called TCP/IP and most of us ordinary mortals have been perplexed or even intimidated by what we have seen or read. So let us begin this discussion on the right foot by saying that although PE1CHL NET is a variant of TCP/IP it is really not necessary to know anything about it to use this excellent piece of software to enhance our enjoyment of our satellite operations. The few things we do need to know will be explained in the following pages in terms which, hopefully, will be understood by anyone interested. Those with PhD degrees and other Technical types need read no further as you will not only be bored but you will not learn anything you don't know already. WHAT IS TCP/IP The common definition says that TCP/IP is a set of protocols developed to allow cooperating computers to share resources across a network. Very clear Right ? Wrong, we still don't know what it is. Well lets try again. A protocol is a set of specifications which allows a software programmer to write a program which does something special such as manipulate files. So TCP/IP is a program which collects together a series of programs which allows computers to work efficiently in a network. It also allows your computer to do specific things without being hooked into a network so from here on we are going to forget about networks and all the theory and big words which go with network operations. We still don't know what TCP/IP really means and I am not going to divulge this secret because it is closely guarded. All I can tell you is that TCP and IP are two protocols which have something to do with the provision of services to the network and as this has nothing to do with this discussion lets forget it. WHAT IS FTL0 OK more totally confusing mnemonics but this one we can explain. When Jeff Ward (G0/K8KA) and Harold Price (NK6K) prepared the protocol for the PACSAT system they called it "FILE TRANSFER LEVEL ZERO" which is now commonly known as ftl0 (lower case). This is starting to make sense at last and this describes what PG does, transfer files. Now we are getting somewhere and the light is dawning. What has this to do with TCP/IP and PE1CHL? Well what Rob Janssen(PE1CHL) did was to take the TCP/IP NET (Rob is a professional in these things and understands them) and add ftl0 to all the other protocols. What this does is allows us to do all kinds of neat things with satellites on a stand alone basis or if we are so inclined to hook into a TCP/IP terrestrial network. Of course there is more. What about the broadcast facility which many of us have learned to use and enjoy via PB. Well there is a protocol which describes this and Glory Be it is called BROADCAST. So Rob put this in NET as well so for the rest of this document we are going to talk about some simple applications of ftl0 and broadcast as applied to UOSAT3, also known as uo14. PRELIMINARIES All this is well and good but what has to be done first before we can even think about satellites and files and so on. I thought you might ask this question so lets provide some answers. The software program you need is called PE1CHL NET but will appear with names like PE91005.ZIP. You will find it on uo14 from time to time or you can get it from a friend or whatever. It is free ware and yours for the asking. If all else fails send me a formatted 720K or 1.2Mb disk with a mailer and enough return postage and I will mail you the latest version I have. You should also look for a file called "HISTORY" which will be a great help to you later on but will confuse you totally until you have read and understood this enlightening document. First thing you do of course is to unzip or unarc the file and this will give you at least three files. These will be called:- NET.EXE AUTOEXEC.NET ONEXIT.NET NET.EXE is the file which starts and executes the NET program but it will only do this to your satisfaction after you do some mysterious and magic things with AUTOEXEC.NET as well as teaching your TNC to behave in ways which it may not have been familiar with up to this point or at least you may not have been familiar with. The TNC is probably smarter than you at this time but we are going to change that. A sample of AUTOEXEC.NET will be found at Appendix A and you should follow it with the ensuing text. The following discussion assumes that NET will be configured for UO14. The datalink to the computer will be 19,200 baud and the radio link 9600. Your TNC/9600 modem will be connected to COM1. This is a long and perplexing document and is not particularly friendly mainly because, up until right now, there has been no other documentation. We are going to go through this item by item and make everything friendlier (I hope). It starts off just fine. # PE1CHL-NET configuration file for the PC. The # at the start means it is a comment or REM and so the computer ignores all lines starting with #. You should not ignore them however. Just make sure your version says PC and not ATARI or some other thing you don't have. Of course if you don't have a PC then you have another problem which I can't help you with but nevertheless much of what follows is probably quite applicable and may even be helpful. The next line says: # insert your callsign (in lower case) etc. Do just what it says. For our application it does not matter if you use upper or lower case but it is important if you want to use TCP/IP later. So do it now just in case.The line it is referring to is: setenv CALLSIGN ${CALLSIGN-ki6qe} DO NOT CHANGE ANYTHING except the callsign (in lower case of course). Next we come to: # COM1 connected to NB96 modem(9k6) # Setup COM1 (second line) and COM2 (first line). don't change parameters. No I have not made a mistake. COM2 comes before COM1. You will notice that the COM1 line has been REMed out with a # because we are keeping this simple with only one TNC connected. Aha you say but I want to connect my TNC to COM1. OK you can do that but you must interchange the lines and the numbers 1 and 2. Your lines will now look like this: #attach com 2 ax25 psk 144 4800 n $CALLSIGN-2 attach com 1 ax25 9k6 256 19200 n $CALLSIGN-7 Note that 9k6 is a mnemonic for our TNC and we are going to use that quite often. There is no magic in 9k6. If you don't like it use something else, but be sure to change it wherever 9k6 appears. (A big deal is made above of the order of COM1 and COM2. Actually it is not a big deal and really doesn't matter in most applications. You might run into a case later where it is important so it is recommended you do as suggested above.) We now we come to: # AX25 configuration. We all remember that AX25 is the protocol for normal packet operation don't we ? We have puzzled about and wrestled with Parameters ever since we started into packet radio. Some are more important than others. Here we will see that we can understand the first few lines which start with ax25 digipeat on. Similarly the next four are in plain English and we can look these up in our manual if we have forgotten. But please do not change these unless you understand exactly what you are doing. Now the next four lines appear to be secret as they set four parameters called t1 t2 t3 and t4 and you won't find these in your manual, at least not like this. But I am going to let you into the secret so long as you don't change the numbers. Here is what they mean: t1 is the retry timer. You know it as FRACK. t2 is the response timer or RESPTIME. t3 is the keep-alive timer or CHECK. t4 is the idle timer. This is like the TIMEOUT in your local BBS where it drops you off if you don't type something in a given period of time. Actually none of these are used by ftl0 but they are used by AX25. So if you ever want to use NET for ordinary packet then you will have set these as you would normally. So now you know and won't need to ask any questions will you ? ax25 window 2048. This is the number of bytes that can be received and buffered on an AX25 connection before the program sends RNR. Yes I do know what that means, Receive Not Ready. Now we come to: #Misc settings. Some are obvious, some obscure to say the least. escape F10 means what it says. Use F10 to escape. flow on. If you don't know what this means and want to, read your TNC manual. log c:\net\netnew.log simply sets up a DOS path for a log file. setenv PROMPT "[use EXIT to go back to NET] ${prompt-$p$g} We are all used to EXIT with SHELL and the $p$g prompt most of us use with our DOS. Now the mysterious KISS mode. We find a line: # KISS and AX25 stuff for each TNC connected. Here we only have one TNC so we will only have one set of parameters. You will note the others have been #ed out. (Pounded out). You must remember to put your TNC in KISS mode before running this program. We will discuss KISS more in a minute. The parameters should all be familiar except perhaps ax25 persist. Again it is not important for satellite full duplex operation but is important for half duplex packet. (See below). Now we come to the concept of virtual ports. We have already set up COM1 for our TNC so what are all these other ports. Well they are not really necessary for our satellite work but we might as well try to understand what they are for. The NET program has within it the ability to divide its attention between several connectees coming in on our COM1 port and performing different functions. Each function is associated with a separate virtual port and there is a different SSID for each of these ports. For example an external station can use your station as a digipeater through virtual port 1 using the SSID of 3. (KI6QE-3 for example). Deeper discussion of virtual ports is beyond the scope of this document. Now we are getting to the nitty gritty and something is starting to happen. We see: # initialize KISS TNC on 430. But would you believe it here is another set of secret codes. What in the world are params 1 through 5. They sure look important. And indeed they are and here is the decode: Param 1 is TXDELAY. You may need to experiment with this as it depends on the type of equipment you are using. Values around 50 have been found useful. Param 2 is p-persistance. This together with slottime is a newer and better way of performing the function of DWAIT. DWAIT should be 0 Param 3 is slottime. param 4 is holdtime param 5 is fullduplex (Yes/No) If you do not have fulldup on you will never transmit. Very frustrating. The next five commands start the servers for the virtual ports discussed above: ax25 start bridge. This starts a conference bridge on virtual port 4. ax25 start mheard. This starts the mheard (Calls heard) function on virtual port 3. ax25 netdigi. This starts the digipeater we mentioned above on virtual port 2 ax25 start tnc "= Connect Text =" . This starts a "tnc", where you can be connected. ax25 start tnc2 3=144 4=430. This starts a TNC emulator which is beyond the scope of this discussion. Actually you can #out all these AX25 functions if you are sure you may never need them. Best advice is to leave them in. They won't do any damage. (If you want to see what they are all about in a practical sense and after you have got the program up and running, you can connect to NET (if you have another packet system) and play with these functions.) Finally we have to describe what it is we really want to do. In this case we would like to access UO14 for all the functions of the ftl0 protocol and we would like to receive and instigate broadcasts. broadcast start "\net\bcst" broadcast server uo14 9k6 uosat3-11 256 2 4 1 3 pblist These are the lines which set up the Broadcast function. ftl0 homedir "\net\ftl0" ftl0 server uo14 9k6 uosat3-12 256 2 4 1 3 bbstat "Open" These are the lines which set up the ftl0 function. In each case the first entry specifies a path to a directory in which the relevant files will be found. The second line describes the "server" which will perform the functions. Now a word about servers. We can't quite get away from TCP/IP talk. A server is the hardware and associated software which is going to carry out the specific function. The NET package provides both servers (services) of its own, as described above, and allows access to other servers like the UO14 ftl0 server. The "ftl0 server" commands provide the information it needs for that, and gives a handle ("uo14" in this case) for later reference. ftl0 server uo14 9k6 uosat3-12 256 2 4 1 3 bbstat "Open" This says that we are going to ask uo14 to perform ftl0 functions. It reminds the software that uo14 is 9600 baud (9k6) and that its callsign is uosat3-12. 256 indicates packet length. When you finally get around to loading NET it is going to wait until it detects a bbstat "Open" frame from uo14 before it does anything. More on this later. Oh Boy now we have got to the end of that we should be able to start something useful. STARTUP OK now you have completed the changes necessary to autoexec.net but there are two more things to think about before we can actually load the program. First the TNC. Net is written for KISS mode TNCs and you need to be sure that your TNC is capable of this mode and then to put it into KISS. (KISS means "Keep it simple Stupid" but whoever devised this mnemonic must have had a strange sense of humor. It is anything but simple, at least to us mere mortals.) Actually it is simple as some regard the KISS protocol as too simple but where the confusion arises is for us to distinguish between conv trans and kiss and how to get our TNCs into and out of these modes. Perhaps a few simple words might be helpful. Conversational Mode (conv) is where you talk to the TNC to give it commands. You cannot talk to a connected station when the TNC's prompt says cmd. Transparent Mode (trans) is when your TNC is transparent to you and you can talk to someone you are connected with. You cannot give your TNC commands when in the transparent mode. To get from transparent to conversational mode is usually no more than cntrl-C and typing trans when at the cmd prompt has the reverse effect. Now KISS. When in KISS mode the TNC is transparent like in trans but it passes through binary data to the computer without much manipulation such as converting it to ASCII. Older TNCs such as TNC1 and early PacComm and MFJ units did not have KISS capability. Read your manual carefully to insure you have a KISS TNC. If you have an AEA TNC you are probably in good shape but there are a couple of tricks as we will see in a minute. Lets assume we have a TINY2 (a TNC-2 close clone) and a PC clone computer. First we need a communications program such as PC-TALK or better PROCOMM. Load this and be sure it is configured for the port and speed we set up in AUTOEXEC.NET. (Remember we set the speed at 19,200 and the Port at COM1). Turn on the TNC and you should get a regular sign on message. Now type KISS ON and you will see a cmd. prompt if all is well. Now type RESTART and you will see nothing on the screen. In fact if you try to type anything nothing happens. This is as it should be because your TNC is in KISS mode which means that it is virtually transparent to you and does not want or need to talk to you anymore. If you have an AEA TNC, PK232 for example, there is one thing you should know. As soon as you type KISS ON it becomes dumb and won't let you type RESTART. Do not worry, it has done all this for you. Just carry on as above. If it says Eh? or What? when you type KISS ON your TNC does not have KISS mode. If you are lucky all you will need is some updated firmware. Contact the TNC manufacturer about this. Another little matter which is confusing sometimes. If your TNC has a battery in it it will remain in KISS mode for the life of the battery. Turning it on and off a zillion times will not get it out of KISS mode. Nor will RESET. So once you have it in KISS you do not have to go through all the stuff above each time you turn it on. On the other hand maybe you want to use your TNC in another mode sometimes and it is pretty infuriating to have to take it out of the cabinet, remove the battery jumper, wait X number of minutes, replace the jumper etc. No no you do not have to do this. Buried inside your manual somewhere you will find the secret of getting out of KISS. For the TINY2 what you do is: 1. Depress NUMLOCK on your keypad. 2. Hold down ALT and type 192 on the keypad. 3. Release ALT 4. Hold down ALT and type 255 on the keypad. The TNC will then reset, with the sign on message and default parameters and return to COMMAND mode. Now exit from PROCOMM (Alt-X) and change to whatever directory you have NET.EXE in. NET is recommended. Resist the temptation to type NET at this time because if you do you will get a screen full of moderately unintelligible messages which will dismay you somewhat. On the other hand if you feel adventurous , try it. You will end up with an enigmatic prompt which says net>. Type EXIT and you will get back to the NET directory. What we have not done yet is to load the port driver and for this discussion we will use MBBIOS which you should have found among the files that came with PE1CHL.NET. You will also find a file called MBBCONFG. This program will allow you to set up drivers for up to four COM ports and is tricky in the extreme for us ordinary folk. However if we only need one or two COM ports it is quite benign. Type MBBCONFG and you will get a fairly explanatory screen which should look something like this: SLOT COM# IRQ SLOT TYPE ---- ---- --- ------------------------------- 1 1 4 IBM Async card addressed as COM1 2 2 3 IBM Async card addressed as COM2 3 Slot is unused. If this is what you see and if you have COM1 and COM2 active in your machine you are lucky so hit F10 and forget about it. If you do not have COM2 then enter a 2 in the box at the bottom of the screen and hit enter. You will be confronted with a very puzzling screen but not to worry if we only need to get rid of COM2. Right at the top in the menu you will see an item A. Slot is unused. Simply enter A into the highlighted box and hit F3 twice and you will be back to the NET prompt. If you want to do something more complicated like set up COM3 and COM4, good luck. This is beyond the scope of this dissertation. Now type MBBIOS and your machine will respond with a nice polite message which says "MBBIOS loaded and ready." When you have finished running NET and want to do something else it is important to unload MBBIOS. You do this by typing MBBIOS /U and it will again respond with a nice polite message which says: MBBIOS successfully unloaded. If you fail to do this and try and run PG.EXE for example you will unpredictable and usually unwanted results. There are several other port drivers which may be used and are less touchy than MBBIOS. One that will be mentioned here is X00.SYS. This has to be installed at startup of your computer by including this line in your config.sys file: device = X00.sys E 2 The big disadvantage of this driver is that to unload it you have to take it out of the config.sys file and reboot your computer. Not always convenient and like MBBIOS, if you try and run software which uses I/O functions you will run into trouble. THE NET PROGRAM NOW at long last you can type NET without incurring the wrath of your machine. After a short while you will see a Commercial telling you about the nice folks who prepared this magic and then a simple prompt which says net> At this point this program is somewhat unfriendly and the remainder of this document will try and help you make it a friend for life. You can, of course, type HELP. It will respond to this with a screen full of TCP/IP commands. Just that. No explanation. HELP (Command) does not do much to alleviate this situation but (Command)? sometimes gives you some rather terse reminders. However be not dismayed because there is now a world of data magic awaiting your commands. If you look carefully at this HELP screen you will see ftl0 and Broadcast included therein. These are the commands we are going to use and you can ignore all the others. Now type ftl0 (Enter). Your machine will respond with a message which says "ftl0 takes at least one argument". OK lets give it an argument. Type ftl0 ZZ (Enter). Your machine will respond with this message. ftl0 sub commands: cancel directory download homedir kick post status trace and upload. Now it has condescended to tell us a little more about what it wants so let us explore further. BASIC OPERATIONS Directory The first thing we must understand about NET is that it is a real time on line type program. It works with a satellite, in this case uo14, so we are not going to see much activity unless signals are being received. It will not even activate your transmitter unless the satellite is in view. Well the first thing we need is a directory unless we already have one from PG. So let us consider a command like: ftl0 dir uo14 t KI6QE 9111111230 This is not so bad. ftl0 is the protocol, dir (Directory),uo14 is the server, t(to), KI6QE (call sign), 911111230 (Hightime or date/time in ordinary language). After you type this in you will find that nothing will happen for a while. DO NOT TYPE IT IN AGAIN. This will only result in the command being executed twice. If you must type something to boost your morale try: ftl0 status uo14 and the computer will respond with the command you typed in above. This means that it has got the message and wants to be left alone. This is useful to be able to confirm that it has got a batch of stacked commands as we will see below. Do not be alarmed. Nothing is supposed to happen until NET detects a BBSTAT "Open" frame. As soon as this occurs you will see the BBSTAT message on the screen and if there is a free slot available NET will attempt to connect to UO14. As soon as it connects it will ask for the directory of Private Messages to KI6QE from the time indicated above. It will then proceed to download this directory and place it in a file called dirfile.dl and then disconnect. Unfortunately it does not tell you what is in the directory at this stage so we have more work to do. Now among the TCP\IP commands we have SHELL which allows us to exit from NET WITHOUT UNLOADING IT and to execute commands from DOS. We can read the directory by using PFH or a little more elegantly by writing a little batch file to do this. Here is a sample. File LISTDIR.BAT pfh -c c:\net\ftl0\uosat\dirfile.dl pfh -d c:\net\ftl0\uosat\dirfile.dl > dir14.1st jtedit dir14.1st This will put on the screen the most recent directory, with the most recent entry first just by typing listdir ( jtedit is a little screen editor. You can use any one you wish). After you have done this and noted the file names, type EXIT to return to NET. Other possible directory commands include: ftl0 dir uo14 t *KI6QE* 9111111230 This will get multiple address files which include KI6QE as well as files just addressed to KI6QE ftl0 dir uo14 t ALL 9111111230 This will get files addressed to ALL Uploading To upload a file we must have it already prepared with the PACSAT header (use PFH or PFHADD) and placed in the directory c:\net\ftl0\uosat3. If this file is named CA1410T1.OUT, then the appropriate command is: ftl0 upload uo14 c:\net\ftl0\uosat3\ca1410t1.out delete If you have several files to upload you can type the instructions in one after the other before the satellite comes over the horizon. In fact it is better to do this to save time during the actual pass. NET will listen for an OPEN frame and upload all the files you have "stacked" commands for. You will be able to see its progress on the screen. After the file has been uploaded it will be deleted from your disk. If you do not want to do this simply omit the word "delete". Downloading To download a file you must first get a directory (see above) and note the filenames of those files you wish to download. Let us say these are 33e0 and 33dc. You would stack two commands like: ftl0 download uo14 33e0 ftl0 download uo14 33dc This will download as many files as you have stacked with a single connect. Broadcasting A much better and faster way to download files is by Broadcasting. (Just like PB). To do this we use the BROADCAST command like: broadcast download uo14 33e0. Instead of using the ftl0 protocol we are using broadcast. Use this as much as possible in place of download as it does not require a connect and therefore does not occupy a channel thus allowing others to use the satellite while you are still getting your files. Summary to date. Now we have the basics and can go ahead and use UO14. We could have included all of the above in one set of commands like: ftl0 dir uo14 t *ki6qe* 9111141230 ftl0 upload uo14 c:\net\ftl0\uosat\ca1401t1.out broadcast download uo14 33e0 broadcast download uo14 33dc You can do this long before the satellite comes over the horizon and it will execute all of the above, even if you are not in the shack but rather in the sack. One problem, of course, is the directory. The above assumes you have obtained the file names 33e0 and 33dc from a directory obtained in a previous pass. We will address and solve this problem as we get into a discussion on automation. AUTOMATION One of the great things about NET is its great flexibility and really unfathomed potential. We can see from the discussion above that we have already achieved a degree of automation but we still have the problem of the directory which needs us to be there, SHELL out to get the file names, and then return and enter more commands while the satellite is in view. This is a pain, especially for those of us who are poor typists and it generally results in having to follow two passes and to use more satellite time than we need. So what can we do without re-writing the software ? Well we have two very powerful tools at our disposal. Batch Processing and a TCP\IP command post. Batch processing we know about (more or less) but few of us have realized its enormous power and potential and you do not have to be a PhD or even a programmer to use it. We can write very simple little routines which will do gigantic tasks. We already gave an example above which co-ordinated two large software programs to do a needed task without us having to do a lot of typing and remembering complicated commands. If you look at the very end of the example in the appendix you will see a line which you have probably been wondering about. It says source /net/commands.net What this means is that there is a file, commands.net, in the NET directory which contains a bunch of stacked commands which we may have prepared with a word processor or even by some other piece of software. As soon as NET is loaded this tells it to look in this file and load the commands that it contains. This now opens the door to preparing sets of commands even when NET is not loaded. A software module called "OUTMESS" which takes message output from a Bulletin Board ,prepares the messages for upload and writes the appropriate commands.net file is used extensively in the Satellite Gateway System and will be described in another document. But we still have this pesky Directory and Download problem. This is more complicated and takes more TCP\IP stuff to do it. DOWNLOADING The last line in the COMMANDS.NET file will look like this: ftl0 post uo14 source dir Now let us see what this means and does. First note that this is the last of the stacked commands and NET will not execute it until all commands above it have been completed. Remember that one of these was a directory command for all private messages addressed to you. As soon as the stacked commands have been completed NET disconnects from the satellite and looks for a source file called "DIR" and executes the commands it finds there. This is DIR: shell /c clear14.bat source request ftl0 post uo14 source mail What this does is to SHELL to DOS and run a batch file called clear14.bat. This uses two other programs called STAFIND and PFH and some DOS stuff to analyse the Directory just downloaded and write a new file called REQUEST. This will look like this: ftl0 upload uo14 3693 ftl0 upload uo14 35f6 NET then executes these new commands by downloading all the files that were in the directory, disconnects once more, and goes to the next "POST" command in the last line of DIR. This points now to another little source file called "MAIL" which looks like this: shell /c inmess.bat ftl0 post uo14 # So we execute another SHELL to DOS and run yet another batch file called INMESS.BAT. This program uses PFH and PKUNZIP to strip off the PACSAT header and extract the text (Messages) and consolidate them into a file called MAIL-IN.FBB. Presto we have solved the Download problem and all has been accomplished automatically. The above is a synopsis of a quite complex process and more detail will be supplied in another document which will describe in detail the setting up of an automated packet gateway. CONCLUSION This should provide you with enough information to get PE1CHL NET up and running and to perform the same tasks that you have been doing with PG and PB. You may be then tempted to try some automation and it may also whet your appetite enough to explore more complex applications and to venture into the world of TCP/IP. To become really familiar with NET you should now start reading the HISTORY file which hopefully will now be a little easier to follow and understand. If you run into any problems or things you do not understand ask for HELP!!!! There are lots of people out there who will come to your aid including PE1CHL himself. Now as a final and exciting finale to this treatise I am ready to announce that after countless hours of study and research I have finally found out what TCP/IP stands for. TCP = TRANSMISSION CONTROL PROTOCOL IP = INTERNET PROTOCOL Isn't that exciting!!!! ATTACHMENT A # PE1CHL-NET configuration file for PC as amended for KI6QE # # insert your callsign (in lowercase) instead of the callsign below. # don't add an SSID here, and change only the part between - and } # setenv CALLSIGN ${CALLSIGN-ki6qe} # # COM1 connected to NB96 modem(9k6) # Setup COM1 (second line) and COM2 (first line). don't change parameters! # #attach com 2 ax25 psk 120 4800 n $CALLSIGN-7 attach com 1 ax25 9k6 240 19200 n $CALLSIGN-2 # # AX25 configuration # ax25 digipeat on ax25 maxframe 4 ax25 paclen 128 ax25 pthresh 64 ax25 retry 10 ax25 t1 15000 ax25 t2 1500 ax25 t3 1800000 ax25 t4 900000 ax25 window 2048 # # Misc settings # escape F10 flow on # log c:\net\netnew.log setenv PROMPT "[use EXIT to go back to NET] ${PROMPT-$p$g}" # # KISS and AX25 stuff for each TNC connected # mheard 9k6 23 mheard psk 23 #mode 430 datagram #mode 144 datagram #ax25 digipeat 430 gate ax25 digipeat 9k6 gate ax25 persist 9k6 128 5 64 60 900 ax25 persist psk 128 5 64 60 900 ax25 digipeat psk gate # AX25 ports. 1=TNC 2=NetDigi 3=MHEARD 4=Bridge 5=TNC2 6=MBOX # ax25 port 1 conn $CALLSIGN ax25 port 1 digi $CALLSIGN-3 psk gate ax25 port 2 digi $CALLSIGN-8 9k6 gate #ax25 port 3 conn $CALLSIGN-3 144 multi ax25 port 3 conn $CALLSIGN-8 9k6 multi ax25 port 4 conn $CALLSIGN-6 ax25 port 5 conn $CALLSIGN-12 ax25 port 6 conn $CALLSIGN-1 # # initialize KISS TNC on 430 # param 9k6 1 50 param 9k6 2 64 param 9k6 3 30 param 9k6 4 3 param 9k6 5 1 # # initialize KISS TNC on 144 # param psk 1 50 param psk 2 64 param psk 3 30 param psk 4 3 param psk 5 1 # # now we can safely start all servers # ax25 start bridge ax25 start mheard ax25 start netdigi ax25 start tnc "= Connect Text =" #ax25 start tnc2 3=144 4=430 # broadcast start "\net\bcst" broadcast server uo14 9k6 uosat3-11 140 2 4 1 3 pblist broadcast server ao16 psk pacsat-11 244 2 4 1 3 pblist ftl0 homedir "\net\ftl0" ftl0 server ao16 psk pacsat-12 130 1 6 1 3 bbstat "Open" ftl0 server uo14 9k6 uosat3-12 140 2 4 1 3 bbstat "Open" ftl0 server lo19 psk lusat-12 130 1 6 1 3 bbstat "Open" ftl0 trace 00ff at 06:00 source \net\at0100.net #at 18:30 source \net\at0100.net source \net\commands.net